Desktop Management Interface ("DMI") is a standard interface for the exchange of information between applications on a desktop computer system. This information can be used for management or status purposes. DMI was developed and is managed by a group of companies referred to as the Desktop Management Taskforce ("DMTF"). DMTF published the Desktop Management Interface Specification, Version 2.0, on Mar. 29, 1996, which may be obtained from any company that is a member of DMTF, including Dell Computer Corporation in Austin, Texas, and which is hereby incorporated by reference in its entirety.
FIG. 1 illustrates a computer system 10 having installed thereon an implementation of a DMI 11. As shown in FIG. 1, the DMI 11 is a management interface ("MI") 12, a service layer ("SL") 14, and a component interface ("CI") 16. In accordance with DMI specifications, a description of each component of the computer system 10, collectively illustrated in FIG. 1 as components 18, is defined in a management information format ("MIF") file for that component. In particular, each component 18 has a MIF file that describes its manageable characteristics. When a component is initially installed into the computer system 10, the .MIF file for that component is added to an MIF database 19. According to DMI specifications, the SL 14 is a Windows service application and a running windows application. The SL 14 is the central data distribution point for the DMI 11. The MI 12 generally initiates data transfers with a query to the SL 14. The CI 16 is responsible for returning data to or acting on data transferred from the MI 12 via the SL 14. The CI 16 can also initiate data transfers under certain conditions. Such CI transfers are referred to as "indications."
The components 18 are connected to a central processing unit 19a and memory 19b of the computer 10 in a conventional manner via one or more buses 19c.
As used herein, a "component" is a physical or logical entity on a computer system, including hardware, software, or firmware. Components may come with a computer system or be added later. The software code that carries out management actions for a particular component is the "component instrumentation," which is designated in FIG. 1 by a reference numeral 20.
The CI 16 is used by component vendors to describe access to management information and to enable a component to be managed. The CI 16 shields vendors from the complexity of encoding styles and management registration information for the components. The MI 12 is used by applications installed on of the computer system 10, collectively illustrated in FIG. 1 as applications 22, to enable the applications to manage components 18. The MI 12 shields application vendors from having to understand the different mechanisms used to obtain management information from elements within the computer system 10.
The CI 16 and MI 12 are procedural interfaces used as the medium for data transfer. The behavioral mechanics of the CI 16 and MI 12 comprise the data transfer mechanism. The SL 14 is an active, resident piece of code running on the computer system 10 that mediates between the MI 12 and CI 16 and provides access to the MIF database 19.
In implementing DMI specifications, MIF files must be created in adherence with the DMI format. Files created in that format describe components, which have attributes that have values and whose attributes can be assembled into groups. As previously described, a "component" is any hardware, software, or firmware that can be connected to or installed on a computer system. An "attribute" is a characteristic, function, or feature of a component; specifically, a relevant and manageable characteristic. Applications that monitor and control a component utilize its attributes to manage it.
A "group" refers to a group of attributes. Attributes are assembled into groups based on their similarity of function or purpose. Attributes of components have "values." Some of these values are static, such as the component type, while others are dynamic, such as the status of the component (e.g., busy or idle).
.MIF files describe components and their attributes. Each component manufacturer provides a MIF file that describes the characteristics of the component that can be managed. A component's MIF file is installed into the MIF database 19 when the component is installed in the computer system 10. The component makes itself known to the computer system 10 via the MIF database 19.
In the MIF database 19, attributes may have a single value or they may be group attributes defining a table or array of related attributes and their values. Whenever the various attributes in a group define one or more rows in a table, a "key" is needed to define the attribute IDs that are used as indices to the table. By use of the key the particular row and attribute in the table is found.
As previously indicated, some attributes represent static information, while others represent dynamic information. To obtain static information, the request for an attribute value is fielded by the SL 14 and reference is made to the MIF database 19 to respond to the query. The same approach may be used for dynamic information, but the database attribute value may be outdated and therefore inaccurate. To obtain current values of dynamically changing attributes, the DMI makes available component instrumentation code 20 for acquiring the attribute value from its source. When the component instrumentation 20 is used, the SI, 14 branches to the component instrumentation to obtain the latest value for that attribute.
As previously indicated, the MI 12 interfaces with the applications 22 to provide access to the database 19 for management functions. A command is used by the applications 22 to request information through the SL, 14 for a particular component 18. The SL 14 acknowledges receipt of the request and issues as many requests to different component instrumentations 20 as necessary to satisfy the management request. If the initial request was for static information, the SL 14 would find that information in the database 19. However, if the request was for the current state of a component, the SL 14 acts as a mediator between the requesting application, via the MI 12, and the component and addresses the component instrumentation 20 through the CI 16 to obtain the current state of the component. Once obtained, the information is passed onto the requesting application through the MI 12.
Client-server applications that rely on the acquisition of a diverse collection of data from information servers can create a confusing tangle of underlying programmatic access methods needed to retrieve data residing on that data server platform. One drawback to the current implementation of DMI described above is that each time the CI 16 changes, the component instrumentation 20 must also be rewritten, requiring investment of a substantial amount of additional time and money.
Therefore, what is needed is an improved method of performing data retrieval from a diverse collection of data storage devices in a DMI or other similar client-server environment